ETSITS129 210V6.3.0 



(2005-09) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

Charging rule provisioning over Gx interface 

(3GPP TS 29.210 version 6.3.0 Release 6) 



3ji^ 





3GPP TS 29.21 version 6.3.0 Release 6 1 ETSI TS 1 29 21 V6.3.0 (2005-09) 



Reference 



RTS/TSGC-0329210V630 
Keywords 



UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2005. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 29.21 version 6.3.0 Release 6 2 ETSI TS 1 29 21 V6.3.0 (2005-09) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 29.21 version 6.3.0 Release 6 3 ETSI TS 1 29 21 V6.3.0 (2005-09) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions, symbols and abbreviations 7 

3.1 Definitions 7 

3.3 Abbreviations 7 

4 Gx reference point 8 

4.1 Overview 8 

4.2 Charging Rules 8 

4.3 Functionality of the Gx reference point 8 

4.3.1 Initialization and maintenance of connection 8 

4.3.2 Request for charging rules from the TPF 9 

4.3.3 Provision of charging rules from the CRF 9 

4.3.4 Provision of event triggers from the CRF 10 

4.3.5 Provision of charging addresses from the CRF 10 

4.3.6 Indication of bearer termination (from TPF to CRF) 10 

5. Gx Protocol 10 

5.1 Protocol support 10 

5.2 Gx specific AVPs 10 

5.2.1 Bearer-Usage AVP 11 

5.2.2 Charging-Rule-Install AVP 11 

5.2.3 Charging-Rule-Remove AVP 11 

5.2.4 Charging-Rule-Defmition AVP 12 

5.2.5 Charging-Rule-Base-Name AVP 12 

5.2.6 Charging-Rule-Name AVP 12 

5.2.7 Event-Trigger AVP 12 

5.2.8 Metering-Method AVP 13 

5.2.9 Offline AVP 13 

5.2.10 Online AVP 13 

5.2.11 Precedence AVP 13 

5.2.12 Void 14 

5.2.13 Void 14 

5.2.14 Void 14 

5.2.15 Reporting-Level AVP 14 

5.2.16 Void 14 

5.2.17 Void 14 

5.2.18 TFT-Filter AVP 14 

5.2.19 TFT-Packet-Filter-lnformation AVP 15 

5.2.20 ToS-Trafflc-Class AVP 15 

5.2.21 PDP-Session-Operation AVP 15 

5.3 Gx re-used AVPs 15 

5.4 Gx specific Experimental-Result-Code AVP values 16 

5.4.1 Success 17 

5.4.2 Permanent Failures 17 

6 Gx Messages 17 

6.1 Gx Application 18 

6.1.1 CC-Request (CCR) Command 18 

6.1.2 CC-Answer (CCA) Command 18 

6.1.3 Re-Auth-Request (RAR) Command 19 

6.1.4 Re-Auth-Answer (RAA) Command 19 



£75/ 



3GPP TS 29.21 version 6.3.0 Release 6 4 ETSI TS 1 29 21 V6.3.0 (2005-09) 

6.2 Gx over Gy Application 19 

6.2.1 Simultaneous charging rule provision and credit authorization 20 

Annex A (informative): Change history 21 

History 22 



£75/ 



3GPP TS 29.21 version 6.3.0 Release 6 5 ETSI TS 1 29 21 V6.3.0 (2005-09) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the stage 3 specification of the Gx reference point. The functional requirements and the 
stage 2 specifications of the Gx reference point are contained in 3GPP TS 23.125 [3]. The Gx reference point is for 
provisioning service data flow based charging rules between the Traffic Plane Function (TPF) and the Charging Rules 
Function (CRF), also known as Service Data Flow Based Charging Rules Function. 

The present document defines: 

the protocol to be used between TPF and CRF over the Gx reference point; 

the information to be exchanged between TPF and CRF over the Gx reference point. 

Whenever it is possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of Diameter. Where this is not possible, extensions to Diameter are defined 
within the present document. 

3GPP TS 29.21 1 [15] provides callflows for Flow Based Charging, covering the signalling on the Gx reference point. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.002: "Network architecture". 

[3] 3GPP TS 23.125: "Overall high level functionality and architecture impacts of flow based 

charging; Stage 2". 

[4] IETF RFC 3588: "Diameter Base Protocol". 

[5] IETF RFC 2234: "Augmented BNF for syntax specifications: ABNF". 

[6] 3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security". 

[7] 3GPP TS 29.207: "Policy control over Go interface". 

[8] IETF RFC 4006: "Diameter Credit-Control Apphcation". 

[9] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging 

applications". 

[10] 3GPP TS 29.209: "Policy control over Gq interface". 

[II] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting 
packet based services and Packet Data Networks (PDN)". 

[12] IETF RFC 4005: "Diameter Network Access Server Apphcation". 

[13] 3GPP TS 32.251: "Packet Switched (PS) domain charging". 
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[14] 
[15] 
[16] 



3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

3GPP TS 29.211: "Rx Interface and Rx/Gx signalling flows". 

3GPP TS 29.229: "Cx and Dx interfaces based on the Diameter protocol; Protocol details". 



3.1 



Definitions, symbols and abbreviations 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1], in 
3GPP TS 23.125 [3] and the following apply: 

Application Function (AF): element offering applications that use IP bearer resources 

The AF is capable of communicating with the CRF to transfer dynamic charging rules related service information. One 

example of an AF is the P-CSCF of the IM CN subsystem. 

Attribute- Value Pair: See IETF RFC 3588 [4], corresponds to an Information Element in a Diameter message. 

PDF Session: unique association of a subscriber with a network access service given by the combination of MSISDN, 
APN and IP address. A PDP session can consist of one or more PDP contexts. 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

AF Application Function 

AVP Attribute-Value Pair 

CCF Charging Collection Function 

CGF Charging Gateway Function 

CRF Charging Rules Function 

CSCF Call Session Control Function 

DCC Diameter Credit Control 

GCID GPRS Charging ID 

ICID IMS Charging IDentifier 

IM IP Multimedia 

IMS IP Multimedia core network Subsystem 

IMSI International Mobile Subscriber Identity 

OCS Online Charging System 

P-CSCF Proxy-CSCF 

PDGw Packet Data Gateway 

PLMN Public Land Mobile Network 

QoS Quality of Service 

SBLP Service Based Local Policy 

S-CSCF Serving-CSCF 

SDF Service Data Flow 

SGSN Serving GPRS Support Node 

SIP Session Initiation Protocol 

TPF Traffic Plane Function 

UE User Equipment 

WAP Wireless Application Protocol 

WLAN Wireless LAN 
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Gx reference point 



4.1 Overview 

The Gx reference point is used for provisioning service data flow based charging rules. The reference point is located 
between the Traffic Plane Function (TPF) and the Charging Rules Function (CRF), also known as Service Data Flow 
Based Charging Rules Function. The stage 2 level requirements for the Gx reference point are defined in 
3GPPTS 23.125 [3]. 



4.2 Charging Rules 



Charging rules determine how service data flows are identified and charged. The TPF shall apply charging rules by 
evaluating received packets against service data flow filters. When a packet matches a service data flow filter, the 
packet matching process for that packet is completed, and the charging rule for that filter shall be applied. 

Charging rules may be: 

Pre-defined and active within the TPF, i.e. default rules that are configured within the TPF. 

Pre-defined within the TPF but not active, i.e. charging rules that can be activated dynamically over the Gx 
reference point. 

Pre-defined within the CRF and provided by the CRF, i.e. charging rules that can be installed dynamically over 
the Gx reference point. 

Dynamically generated and provided by the CRF, i.e. charging rules that can be installed dynamically over the 
Gx reference point, (e.g. dynamic charging rules for example for IMS peer to peer service data flows, where both 
the service data flow filter and the charging rule are identified dynamically). 

NOTE: Whether the charging rule is pre-defined or dynamically generated by the CRF does not impact the 
procedures at the Gx reference point. 

Pre-defined rules within the TPF may be grouped allowing CRF to dynamically activate a set of rules over the 
Gx reference point. 

A charging rule shall consist of a charging rule name, charging key (i.e. rating group), service identifier, service flow 
filter and other charging parameters. The charging rule name shall be used to reference to a charging rule in the 
communication between the TPF and the CRF. The service identifier shall be used to identify the service or the service 
component the service data flow relates to. The service flow filter shall be used to select the traffic for which the 
charging rule applies. The charging parameters define whether online and offline charging interfaces are used, what is 
to be metered in offline charging, what is the precedence of the charging rule, on what level the TPF shall report the 
usage related to the charging rule, etc. For different charging rules with overlapping service data flow filter, the 
precedence of the charging rule determines which of these charging rules is applicable. Charging rule also includes 
Application Function record information for enabling charging correlation between the application and bearer layer if 
the Application Function has provided this information via the Rx interface. For IMS this includes the IMS Charging 
Identifier (ICID) and flow identifiers. See the AVPs in clauses 5.2 and 5.3. 

4.3 Functionality of the Gx reference point 
4.3.1 Initialization and maintenance of connection 

The initialization and maintenance of the connection between each interworking CRF and TPF pair is defined by the 
underlying protocol. Establishment and maintenance of connections between Diameter nodes is described in IETF 
RFC 3588 [4]. 
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4.3.2 Request for charging rules from the TPF 

The TPF shall indicate, via the Gx reference point, a request for charging rules in the following instances. 

1) At bearer establishment: 

The TPF shall send a CC-Request with CC-Request-Type AVP set to the value 'INITIAL_REQUEST'. The 
TPF shall supply user identification and other attributes to allow the CRF to identify the charging rules to be 
applied. The other attributes shall include the type of the radio access technology (e.g UTRAN, GERAN, 
WLAN) and the UE IP address. For GPRS, information about the user equipment (e.g. IMEISV), QoS 
negotiated, SGSN Address, SGSN country and network codes, APN, TFT and indication if the bearer is used 
as IMS signalling PDP context shall be provided. 

2) At bearer modification if an Event trigger is met: 

The TPF shall send a CC-Request with CC-Request-Type AVP set to the value 'UPDATE_REQUEST'. The 
TPF shall supply those attributes that have changed within the charging rule request. The bearer attributes 
that have been modified since the last request are required items. 

3) When the specific event of the Event trigger is detected: 

The TPF shall send a CC-Request with CC-Request-Type AVP set to the value 'UPDATE_REQUEST'. The 
TPF shall supply those attributes that have changed within the charging rule request. The attributes that have 
been modified since the last request are required items. 

NOTE: For GPRS the same procedures are applied to both primary and secondary PDP context establishments. 

4.3.3 Provision of charging rules from the CRF 

The CRF shall indicate, via the Gx reference point, charging rules to be applied at the TPF. This may be: 

in response to a request for charging rules., i.e. to a request made as described in the preceding section; or 

unsolicited by the TPF, e.g. in response to information provided to the CRF via the Rx reference point, or in 
response to an internal trigger within the CRF. 

For each request from the TPF and upon the unsolicited provision the CRF shall provision zero or more charging rules. 
The CRF may perform an operation on a single charging rule by one of the following means: 

Reference to a charging rule predefined at the TPF and the required action, i.e. activation or deactivation of 
charging rule, or 

Reference to a charging rule previously provided by the CRF to the TPF and the required action and possibly 
modified information, e.g. modification or removal of charging rule, or 

Complete charging rule definition and the required action, i.e. installation of a charging rule 

As an alternative to providing a single charging rule, the CRF may provide a reference to a group of charging rules 
predefined at the TPF and the required action, i.e. activation or deactivation of the group. 

The CRF may combine multiple of the above charging rule operations in a single command. 

To activate a predefined charging rule at the TPF, charging rule name shall be used as a reference to the predefined 
charging rule. To activate a group of predefined charging rules within the TPF (e.g. gold users or gaming services) 
charging rule base name shall be used as a reference to the group of predefined charging rules. The same two types of 
references shall be used for deactivating predefined and removing CRF-provided charging rules from a bearer, which 
for GPRS is a PDP context. See the AVP definitions in clause 5.2. 

To install or modify a CRF defined charging rule, the Charging-Rule-Definition AVP shall be used. If a charging rule 
with the same charging rule name already exists at the TPF, the new charging rule shall update the currently installed 
charging rule. If the existing charging rule already has charging attributes also included in the new charging rule 
definition, the existing attributes shall be overwritten. Any charging attribute in the existing charging rule not included 
in the new charging rule definition shall remain valid. 
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4.3.4 Provision of event triggers from tine CRF 

The CRF may provide event triggers to the TPF using the charging rule provision procedure. Event triggers are used to 
determine which bearer modification or specific event causes the TPF to re-request charging rules. Event triggers apply 
for a bearer and may be included to the initial or subsequent charging rule provision. 

4.3.5 Provision of cinarging addresses from tine CRF 

Within the initial charging rule provisioning only, the CRF may provide CCF and/or OCS addresses to the TPF defining 
the offline and online charging system addresses respectively. These shall overwrite any predefined addresses at the 
TPF. Both primary and secondary addresses for CCF and/or OCS shall be provided simultaneously. Provisioning CCF 
or OCS addresses without charging rules for offline or online charged service data flows, respectively, shall not be 
considered as an error since such charging rules may be provided in later provisioning. 

4.3.6 Indication of bearer termination (from TPF to CRF) 

The TPF indicates to the CRF, via the Gx reference point, that a bearer is terminated via the release of the 
corresponding DCC session. TheTPF shall send a CC-Request with CC-Request-Type AVP set to the value 
TERMINATION_REQUEST. The bearer termination indication identifies the bearer being removed by the usage of the 
corresponding DCC session. For GPRS, the TPF indicates the release of the PDP session with the value 'PDP- 
SESSION-TERMINATION' of the PDP-Session-Operation AVP. 

Upon the bearer termination, the CRF may provision charging rules for any remaining bearers. In case of GPRS, these 
are the remaining PDP context(s) in a PDP session for which a PDP context is terminated. The CRF provisions the 
charging rules for any remaining bearer using the unsolicited provision procedure. 



5. Gx Protocol 
5.1 Protocol support 

The Gx reference point shall be based on Diameter as specified in RFC 3588 [4] and Diameter Credit Control 
Application as specified in RFC 4006 [8] except as modified by the defined Gx specific procedures and AVPs. Unless 
otherwise specified, the procedures (including error handling and unrecognized information handling) are unmodified. 
In addition to the AVPs defined within the clause 5.2, the existing Diameter AVPs are reused as specified in sub-clause 
5.3. Diameter messages from the Diameter base application (RFC 3588 [4]) and DCC (RFC 4006 [8]) are reused as 
specified in clause 6. 

With regard to the Diameter protocol defined over the Gx reference point, the CRF acts as a Diameter server, in the 
sense that it is the network element that handles charging rule requests for a particular realm. The TPF acts as the 
Diameter Client, in the sense that it is the network element requesting charging rules. 



5.2 Gx specific AVPs 



Table 5.2 describes the Diameter AVPs defined for the Gx reference point, their AVP Code values, types, possible flag 
values and whether or not the AVP may be encrypted. The Vendor-Id header of all AVPs defined in the present 
document shall be set to 3GPP (10415). 



£75/ 



3GPP TS 29.210 version 6.3.0 Release 6 



11 



ETSI TS 129 210 V6.3.0 (2005-09) 



Table 5.2: Gx specific Diameter AVPs 











AVP Flag rules (note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type (note 2) 


Must 


May 


Should 
not 


Must 
not 


May Encr. 


Bearer-Usage 


1000 


5.2.1 


Enumerated 


M,V 


P 






Y 


Charging-Rule-lnstall 


1001 


5.2.2 


Grouped 


M,V 


P 






Y 


Charging-Rule-Remove 


1002 


5.2.3 


Grouped 


M,V 


P 






Y 


Charging-Rule-Definition 


1003 


5.2.4 


Grouped 


M,V 


P 






Y 


Charging-Rule-Base-Name 


1004 


5.2.5 


OctetString 


M,V 


P 






Y 


Charging-Rule-Name 


1005 


5.2.6 


OctetString 


M,V 


P 






Y 


Event-Trigger 


1006 


5.2.7 


Enumerated 


M,V 


P 






Y 


Metering-Method 


1007 


5.2.8 


Enumerated 


M,V 


P 






Y 


Offline 


1008 


5.2.9 


Enumerated 


M,V 


P 






Y 


Online 


1009 


5.2.10 


Enumerated 


M,V 


P 






Y 


Precedence 


1010 


5.2.11 


Unsigned32 


M,V 


P 






Y 


Reporting-Level 


1011 


5.2.15 


Enumerated 


M,V 


P 






Y 


PDP-Session-Operation 


1015 


5.2.21 


Enumerated 


M,V 


P 






Y 


TFT-Filter 


1012 


5.2.18 


IPFJIterRule 


M,V 


P 






Y 


TFT-Packet-Filter-lnformation 


1013 


5.2.19 


Grouped 


M,V 


P 






Y 


ToS-Traffic-Class 


1014 


5.2.20 


OctetString 


M,V 


P 






Y 


NOTE 1 : The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit 
denoted as 'V, indicates whether the optional Vendor-ID field is present in the AVP header. For further 
details, see RFC 3588 [4]. 

NOTE 2: The value types are defined in RFC 3588 [4]. 



5.2.1 Bearer-Usage AVP 



The Bearer-Usage AVP (AVP code 1000) is of type Enumerated, and it shall indicate how the bearer is being used. If 
the Bearer-Usage AVP has not been previously provided, its absence shall indicate that no specific information is 
available. If the Bearer-Usage AVP has been provided, its value shall remain valid until it is provided the next time. The 
following values are defined: 

GENERAL (0) 
This value shall indicate no specific bearer usage information is available. 

1MS_S1GNALL1NG(1) 
This value shall indicate that the bearer is used for IMS signalling only. 



5.2.2 Charging-Rule-lnstall AVP 



The Charging-Rule-lnstall AVP (AVP code 1001) is of type Grouped, and it is used to activate, install or modify 
charging rules for a bearer as instructed from the CRF to the TPF. 

For installing a new charging rule or modifying a Charging Rule already installed, Charging-Rule-Name AVP and 
Charging-Rule-Definition AVP shall be used. 

For activating a specific charging rule predefined at the TPF, Charging-Rule-Name AVP shall be used as a reference for 
that charging rule. The Charging-Rule-Base-Name AVP is a reference that may be used for activating a group of 
charging rules predefined at the TPF. 



AVP Format: 



Charging-Rule-lnstall 



< AVP Header: 1001 > 

* [ Charging-Rule-Definition 
* [ Charging-Rule-Name 1 
* [ Charging-Rule-Base-Name ] 
* [ AVP ] 



5.2.3 Charging-Rule-Remove AVP 



The Charging-Rule-Remove AVP (AVP code 1002) is of type Grouped, and it is used to deactivate or remove charging 
rules from a bearer. 
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Charging-Rule-Name AVP is a reference for a specific charging rule at the TPF to be removed or for a specific 
charging rule predefined at the TPF to be deactivated. The Charging-Rule-Base-Name AVP is a reference for a group of 
charging rules predefined at the TPF to be deactivated. 

AVP Format: 

Charging-Rule-Remove ::= < AVP Header: 1002 > 

* [ Charging-Rule-Name ] 

* [ Charging-Rule-Base-Name ] 

* [ AVP ] 

5.2.4 Charging-Rule-Definition AVP 

The Charging-Rule-Definition AVP (AVP code 1003) is of type Grouped, and it defines the charging rule for a service 
flow sent by the CRF to the TPF. The Charging-Rule-Name AVP uniquely identifies the charging rule for a bearer and 
it is used to reference to a charging rule in communication between the TPF and the CRF. The Flow-Description 
AVP(s) determines the traffic that belongs to the service flow. 

If optional AVP(s) within a Charging-Rule-Definition AVP are omitted, but corresponding information has been 
provided in previous Gx messages, the previous information remains valid. If Flow-Description AVP(s) are supplied, 
they replace all previous Flow-Description AVP(s). If Flows AVP(s) are supplied, they replace all previous Flows 
AVP(s). 

Flows AVP may appear if and only if AF-Charging-Identifier AVP is also present. 

AVP Format: 

Charging-Rule-Definition ::= < AVP Header: 1003 > 

Charging-Rule-Name } 
Service-Identifier ] 
Rating-Group ] 
Flow-Description ] 
Reporting-Level ] 
Online ] 
Offline ] 
Metering-Method ] 
Precedence ] 

AF-Charging-Identif ier ] 
Flows ] 
AVP ] 

5.2.5 Charging-Rule-Base-Name AVP 

The Charging-Rule-Base-Name AVP (AVP code 1004) is of type OctetString, and it indicates the name of a 
pre-defined group of charging rules residing at the TPF. 

5.2.6 Charging-Rule-Name AVP 

The Charging-Rule-Name AVP (AVP code 1005) is of type OctetString. For charging rules provided by the CRF it 
uniquely identifies a charging rule for a bearer. For charging rules pre-defined at the TPF it uniquely identifies a 
charging rule within the TPF. 



5.2.7 Event-Trigger AVP 



The Event-Trigger AVP (AVP code 1006) is of type Enumerated, and it indicates an event that shall cause a re-request 
of charging rules. The following values are defined: 

SGSN_CHANGE (0) 
This value shall be used to indicate that upon the change of the serving SGSN charging rules shall be requested. 

QOS_CHANGE(l) 
This value shall be used to indicate that upon a QoS change charging rules shall be requested. 

RAT_CHANGE (2) 
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This value shall be used to indicate that upon a RAT change charging rules shall be requested. 

TFT_CHANGE (3) 
This value shall be used to indicate that upon a TFT change charging rules shall be requested. 

PLMN_CHANGE (4) 
This value shall be used to indicate that upon a PLMN change charging rules shall be requested. 

5.2.8 Metering-Method AVP 

The Metering-Method AVP (AVP code 1007) is of type Enumerated, and it defines what parameters shall be metered 
for offline charging. The following values are defined: 

DURATION (0) 
This value shall be used to indicate that the duration of the service flow shall be metered. 

VOLUME (1) 
This value shall be used to indicate that volume of the service flow traffic shall be metered. 

DURAT10N_V0LUME (2) 
This value shall be used to indicate that the duration and the volume of the service flow traffic shall be metered. 

5.2.9 Offline AVP 

The Offline AVP (AVP code 1008) is of type Enumerated, and it defines whether the offline charging interface from 
the TPF for the associated charging rule shall be enabled. The absence of this AVP indicates that the default 
configuration shall be used. The following values are defined: 

DlSABLE_OFFLINE (0) 
This value shall be used to indicate that the offline charging interface for the associated charging rule shall be disabled. 

ENABLE_OFFLlNE (1) 
This value shall be used to indicate that the offline charging interface for the associated charging rule shall be enabled. 

5.2.10 Online AVP 

The Online AVP (AVP code 1009) is of type Enumerated, and it defines whether the online charging interface from the 
TPF for the associated charging rule shall be enabled. The absence of this AVP indicates that the default configuration 
shall be used. The following values are defined: 

DlSABLE_ONLlNE (0) 
This value shall be used to indicate that the online charging interface for the associated charging rule shall be disabled. 

ENABLE_ONLlNE(l) 
This value shall be used to indicate that the online charging interface for the associated charging rule shall be enabled. 

5.2.11 Precedence AVP 

The Precedence AVP (AVP code 1010) is of type Unsigned32, and it defines the precedence of a charging rule in case 
of overlapping charging rules. A charging rule with the Precedence AVP with lower value shall take the priority over a 
charging rule with the Precedence AVP with higher value. The Precedence AVP is also used to indicate the evaluation 
precedence of the TFT packet filters. 
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5.2.12 Void 

5.2.13 Void 

5.2.14 Void 

5.2.15 Reporting-Level AVP 

The Reporting-Level AVP (AVP code 101 1) is of type Enumerated, and it defines on what level the TPF reports the 
usage for the related charging rule. The following values are defined: 

CHARGING_RULE_LEVEL (0) 
This value shall be used to indicate that the usage shall be reported on charging rule level. 

RATING_GROUP_LEVEL (1) 
This value shall be used to indicate that the usage shall be reported on rating group level. 

5.2.16 Void 

5.2.17 Void 

5.2.18 TFT-Filter AVP 

The TFT-Filter AVP (AVP code 1012) is of type IPFilterRule, and it contains the flow filter for one TFT packet filter. 
The TFT-Filter AVP is derived from the Traffic Flow Template (TFT) defined in 3GPP TS 24.008 [14]. The following 
information shall be sent: 

Action shall be set to "permit". 

Direction shall be set to "out". 

Protocol shall be set to the value provided within the TFT packet filter parameter "Protocol Identifier/Next 
Header Type". If the TFT packet filter parameter "Protocol Identifier/Next Header Type" is not provided within 
the TFT packet filter, Protocol shall be set to "IP". 

Source IP address (possibly masked). The source IP address shall be derived from TFT packet filter parameters 
"Source address" and "Subnet Mask". The source IP address shall be set to "any", if no such information is 
provided in the TFT packet filter. 

Source and destination port (single value, list or ranges). The information shall be derived from the 
corresponding TFT packet filter parameters. Source and/or destination port(s) shall be omitted if such 
information is not provided in the TFT packet filter. 

The Destination IP address shall be set to "assigned". 
The IPFilterRule type shall be used with the following restrictions: 

No options shall be used. 

Destination IP address shall be wildcarded. 

The invert modifier " !" for addresses shall not be used. 
The direction "out" refers to downlink direction. 
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5.2.19 TFT-Packet-Filter-lnformation AVP 

The TFT-Packet-Filter-Information AVP (AVP code 1013) is of type Grouped, and it contains the information from a 
single TFT packet filter including the evaluation precedence, the filter and the Type-of-Service/Traffic Class sent from 
the TPF to the CRF. The TPF shall include one TFT-Packet-Filter-lnformation AVP for each TFT packet filters 
applicable at a PDP context in separate TFT-Packet-Filter-lnformation AVPs within each charging rule request, 
corresponding to that PDP context. TFT-Packet-Filter-lnformation AVPs are derived from the Traffic Flow Template 
(TFT) defined in 3GPP TS 24.008 [14]. When SBLP is used the packet filters shall be omitted. 

AVP Format: 

TFT-Packet-Filter-Information ::= < AVP Header: 1013> 

[ Precedence ] 
[ TFT-Filter ] 
[ ToS-Traffic-Class ] 

5.2.20 ToS-Traffic-Class AVP 

The ToS-Traffic-Class AVP (AVP code 1014) is of type OctetString, and it contains the Type-of-Service/Traffic-Class 
of a TFT packet filter as defined in 3GPP TS 24.008 [14]. 



5.2.21 PDP-Session-Operation AVP 



The PDP-Session-Operation AVP (AVP code 1015) is of type Enumerated. It is only applicable for GPRS. The 
following value is defined: 

PDP-SESSION-TERMINATION (0) 

This value is used to report in an indication of bearer termination that this indication refers to the last PDP context 
within a PDP session. 

5.3 Gx re-used AVPs 

The table 5.3 lists the Diameter AVPs re-used by the Gx reference point from existing Diameter Applications, reference 
to their respective specifications and short description of their usage within the Gx reference point. Other AVPs from 
existing Diameter Applications, except for the AVPs from Diameter base protocol, do not need to be supported. The 
AVPs from Diameter base protocol are not included in table 5.3, but they are re-used for the Gx reference point. Where 
3GPP Radius VSAs are re-used, they shall be translated to Diameter AVPs as described in IETF RFC 4005 [12] with 
the exception that the 'M' flag shall be set and the "P' flag may be set. 
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Table 5.3: Gx re-used Diameter AVPs 



Attribute Name 


Reference 


Description 


3GPP-GPRS-Negotiated- 
QoS-Profile 


3GPPTS 29.061 [11] 


For GPRS tfie QoS of tine PDP context 


3GPP-RAT-Type 


3GPPTS 29.061 [11] 


Indicate which Radio Access Technology is currently serving 
the UE. 


3GPP-SGSN-Address 


3GPPTS 29.061 [11] 


For GPRS the IPv4 address of the SGSN 


3GPP-SGSN-IPV6- 
Address 


3GPPTS 29.061 [11] 


For GPRS the IPv6 address of the SGSN 


3GPP-SGSN-MCC-MNC 


3GPPTS 29.061 [11] 


For GPRS the MCC and the MNC of the SGSN 


AF-Charging-ldentifier 


3GPPTS 29.209 [10] 


The AF charging identifier that may be used in charging 
correlation. For IMS the ICID. This AVP may only be included 
when CHARGING RULE LEVEL reporting is being used. 


Called-Station-ID 


IETF RFC 4005 [12] 


The address the user is connected to. For GPRS the APN. 


CG-Request-Number 


IETF RFC 4006 [8] 


The number of the request for mapping requests and 
answers 


CG-Request-Type 


draft-ietf-aaa-diameter- 
cc-06.txt [8] 


The type of the request (initial, update, termination) 


Charging-lnformation 


3GPPTS 29.229 [16] 


The Charging-lnformation AVP is of type Grouped, and 
contains the addresses of the charging functions in the 
following AVPs: 

• Primary-Event-Charging-Function-Name is of type 
DiameterURI and defines the address of the primary 
online charging system for the bearer. The absence 
of the protocol definition in the DiameterURI shall 
indicate the default protocol defined for the Gy 
interface. 

• Secondary-Event-Charging-Function-Name is of 
type DiameterURI and defines the address of the 
secondary online charging system for the bearer. 
The absence of the protocol definition in the 
DiameterURI shall indicate the default protocol 
defined for the Gy interface. 

• Primary-Charging-Collection-Function-Name is of 
type DiameterURI and defines the address of the 
primary offline charging system for the bearer. The 
absence of the protocol definition in the 
DiameterURI shall indicate the default protocol 
defined for the Gz interface. 

• Secondary-Charging-Collection-Function-Name is 
of type DiameterURI and defines the address of the 
secondary offline charging system for the bearer. 
The absence of the protocol definition in the 
DiameterURI shall indicate the default protocol 
defined for the Gz interface. 


Flow-Description 


3GPPTS 29.209 [10] 


Defines the service flow filter parameters for a charging rule 


Flows 


3GPPTS 29.209 [10] 


The flow identifiers of the IP flows related to a charging rule 
as provided by the AF. May be only used in charging 
correlation together with AF-Charging-ldentifier AVP. 


Framed-IP-Address 


IETF RFC 4005 [12] 


The IPv4 address allocated for the user. 


Framed-IPv6-Prefix 


IETF RFC 4005 [12] 


The IPv6 address prefix allocated for the user 


Rating-Group 


IETF RFC 4006 [8] 


The charging key for the charging rule used for rating 
purposes 


Service-Identifier 


IETF RFC 4006 [8] 


The identity of the service or service component the service 
data flow in a charging rule relates to. 


Subscription-Id 


IETF RFC 4006 [8] 


The identification of the subscription (IMSI, MSISDN, etc) 


User-Equipment-Info 


IETF RFC 4006 [8] 


The identification and capabilities of the terminal (IMEISV, 
etc.) 



5.4 Gx specific Experimental-Result-Code AVP values 

There are two different types of errors in Diameter; protocol and application errors. A protocol error is one that occurs 
at the base protocol level, those are covered in the Diameter BASE RFC 3588 [4] specific procedures. Application 
errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application. 
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Diameter BASE RFC 3588 [4] defines a number of Result-Code AVP values that are used to report protocol errors and 
how those are used. Those procedures and values shall apply for the present specification. 

Due to the Gx specific AVPs, new applications errors can occur. The Gx specific errors are described by the 
Experimental-Result-Code AVP in this clause, below. According to RFC 3588 [4], the diameter node reports only the 
first error encountered and only either one Result-Code AVP or one Experimental-Result AVP is included in the 
Diameter answer. 

5.4.1 Success 

Result Codes that fall within the Success category are used to inform a peer that a request has been successfully 
completed. 

The Result-Code AVP values defined in Diameter BASE RFC 3588 [4] shall be appUed. 

5.4.2 Permanent Failures 

Errors that fall within the Permanent Failures category shall be used to inform the peer that the request failed, and 
should not be attempted again. 

The Result-Code AVP values defined in Diameter BASE RFC 3588 [4] are applicable. Also the following specific Gx 
Experimental-Result-Codes values are defined: 

DIAMETER_ERROR_INITIAL_PARAMETERS (5 140) 

This error shall be used when the set of bearer information needed in the CRF for rule selection is incomplete 
or erroneous for the decision to be made. (e.g. QoS, SGSN address, RAT type, TFT...) 

DIAMETER_ERROR_TRIGGER_EVENT (5141) 

This error shall be used when the set of bearer information sent in a CCR originated due to a trigger event 
been met is incoherent with the previous set of bearer information for the same bearer, (e.g event trigger met 
was RAT changed, and the RAT notified is the same as before) 



Gx Messages 



Gx Messages are carried within the Diameter Application(s) described in the sub-clauses below. These Applications are 
defined as vendor specific Diameter applications, where the vendor is 3GPP. The vendor identifier assigned by lANA to 
3GPP ( http://www.iana.org/assignments/enterprise-numbers ) is 10415. 

The TPF and the CRF shall advertise the support of the 3GPP vendor specific Diameter Application for the Gx 
Application and/or the Gx over Gy Application by including the value of the appropriate application identifier(s) in the 
Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in RFC 3588 [4], i.e. as part 
of the Vendor-Specific-Application-Id AVP. The Capabilities-Exchange-Request and Capabilities-Exchange-Answer 
commands are specified in the Diameter Base Protocol. 

Existing Diameter command codes from the Diameter base protocol RFC 3588 [4] and the Diameter Credit Control 
Application RFC 4006 [8] are used with the Gx specific AVPs specified in clause 5.2. The Diameter Credit Control 
Application AVPs and AVPs from other Diameter applications that are re-used are defined in clause 5.3. Due to the 
definition of these commands there is no possibility to skip the Auth-Application-Id AVP and use the Vendor-Specific- 
Application-Id AVP instead. Therefore the Gx application identifier shall be included in the Auth- Application-Id AVP. 

In the GPRS case, the association between the PDP contexts and the Diameter Credit Control sessions shall be done in a 
one-to-one basis : Each PDP context shall map to a DCC session. The release of a PDP Context shall be indicated by 
the release of the related DCC session. The CRF may identify all PDP contexts belonging to the same PDP session by 
considering the IPv4 UE IP address provided within the Framed-IP- Address AVP or the IPv6 UE IP address prefix 
provided within the Framed-IPv6-Prefix AVP, the APN provided within the Called-Station-ID AVP, and the Origin- 
Host AVP received in the CCR. For all PDP contexts belonging to the same PDP session, the UE IP address (prefix) 
and APN are equal. The CRF only needs to take the Origin-Host AVP into account, if the CRF is connected to several 
TPFs. 
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6.1 Gx Application 



Gx reference point shall use Diameter Gx Application as described in this chapter when the CRF functionality is 
implemented in a standalone device. The Auth-Application-Id for the Gx Application is 16777224 as allocated by 
lANA. This value shall be included in the Auth- Application-Id AVP for the CCR, CCA and RAR commands. 

A Gx Application specific Auth- Application-Id is used together with the command code to identify the Gx Application 

messages. 



6.1 .1 CC-Request (CCR) Command 



The CCR command, indicated by the Command-Code field set to 272 and the 'R' bit set in the Command Flags field, is 
sent by the TPF to the CRF in order to request charging rules for a bearer. The CCR command is also sent by the TPF to 
the CRF in order to indicate the termination of the bearer. 



Message Format: 



<CC-Request> 



< Diameter Header: 272, REQ, PXY > 

< Session-Id > 
Auth-Application-Id } 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
CC-Request-Type } 
CC-Request-Number } 
Destination-Host ] 
Origin-State-Id ] 
Subscription-Id ] 
Framed-IP-Address ] 
Framed-IPv6-Pref ix ] 
3GPP-RAT-Type ] 
Termination-Cause ] 
User-Equipment-Info ] 
3GPP-GPRS-Negotiated-QoS-Profile 
3GPP-SGSN-MCC-MNC ] 
3GPP-SGSN-Address ] 
3GPP-SGSN-IPv6-Address ] 
Called-Station-ID ] 
Bearer-Usage ] 
PDP-Session-Operation ] 
TFT-Packet-Filter-Information ] 
Proxy-Info ] 
Route-Record ] 
AVP 1 



6.1 .2 CC-Answer (CCA) Command 

The CCA command, indicated by the Command-Code field set to 272 and the 'R' bit cleared in the Command Flags 
field, is sent by the CRF to the TPF in response to the CCR command. It is used to provision charging rules and event 
triggers for the bearer. The primary and secondary CCF and/or primary and secondary OSC addresses may be included 
in the initial provisioning. 

Message Format: 



<CC-Answer> 



< Diameter Header: 272, 

< Session-Id > 
Auth-Application-Id } 
Origin-Host } 
Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
CC-Request-Type } 
CC-Request-Number } 
Event-Trigger ] 
Origin-State-Id ] 
Charging-Rule-Remove ] 
Char ging-Rule- Ins tall 
Charging-Inf ormation ] 
Error-Message ] 
Error-Reporting-Host ] 
Failed-AVP ] 
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■ [ Proxy-Info ] 

■ [ Route-Record 

■ [ AVP ] 



6.1 .3 Re-Auth-Request (RAR) Command 



The RAR command, indicated by the Command-Code field set to 258 and the 'R' bit set in the Command Flags field, is 
sent by the CRF to the TPF in order to initiate the provision of unsolicited charging rules for an existing bearer. The 
RAR command shall be followed by a CCR command from the TPF requesting charging rules for the bearer in 
question. 



Message Format: 



<RA-Request> 



Diameter Header: 258, REQ, PXY > 
Session-Id > 
Auth-Application-Id } 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
Destination-Host } 
Re-Auth-Request-Type } 
Origin-State-Id ] 
Proxy-Info ] 
Route-Record ] 
AVP] 



6.1 .4 Re-Auth-Answer (RAA) Command 

The RAA command, indicated by the Command-Code field set to 258 and the 'R' bit cleared in the Command Flags 
field, is sent by the TPF to the CRF in response to the RAR command. 



Message Format: 



<RA-Answer> 



< Diameter Header; 258, 

< Session-Id > 
Origin-Host } 
Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
Origin-State-Id ] 
Error-Message ] 
Error-Reporting- Host 
Failed-AVP ] 
Proxy-Info ] 
AVP ] 



6.2 Gx over Gy Application 



The Gy protocol is specified as online charging application in in 3GPP TS 32.299 [9] and TS 32.251 [13] 

The Gx over Gy Application allows to combine in a single message exchange (e.g. CCR-CCA) the Gx functionality of 
charging rule provisioning, and the Gy functionality of credit control for service data flow based online charging. This 
allows creating synergies and signalling savings in case the CRF and the OCS are collocated. 

The Diameter Gx over Gy Application as described in this Clause should be used when the CRF functionality is co- 
located with the Online Charging System (OCS) and both are connected to the TPF via a single interface that comprises 
the Gx and Gy reference points. The Auth-Application-Id for the Gx over Gy Application is 16777225 as allocated by 

lANA. 

A Gx over Gy Application specific Auth-Application-Id is used together with the command code to identify the Gx 
over Gy Application messages. AVPs included within the Gy Service-Information AVP do not need to be included once 
more on command level, as specified for the Gx application. 

For the Gx over Gy Application the association between the bearers and the Diameter Credit Control sessions shall be 
done in a one-to-one basis. In the GPRS case, each PDP context (no matter if it has been established by a primary or 
secondary PDP context establishment) shall map to a Diameter session. The release of a PDP Context shall be indicated 
by the release of the related DCC session. 
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NOTE: This usage of DCC sessions in the Gx over Gy Application is in aUgnment with both the Gx Application 
and the Gy online charging Application. 

The Gx over Gy Application is based on the Diameter Credit Control Application. The Gx over Gy Application shall 
use Gx specific AVPs to fulfil the Gx specific requirements (charging rule provision) and, over the same message, Gy 
functionalities (credit authorization), as follows: 

When only charging rule provision is required the procedures and message content for Gx Application as 
specified in clause 6.1 shall apply, except for the use of DCC subsession. 

When only credit authorization is required the procedures and message content for Gy as specified as online 
charging appHcation in 3GPP TS 32.299 [9] and TS 32.251 [13] shall apply. 

When credit authorization and charging rule provision are required simultaneously, these should be requested 
and provided with a single CCR-CCA message pair (e.g. credit authorization and request for charging rules). The 
AVPs defined in Gy interface to satisfy the credit authorization requirements and the Gx specific and Gx re-used 
AVPs shall be both included in the Diameter messages as needed. The common AVPs shall be included only 
once within the same message. AVPs included within the Gy Service-Information AVP do not need to be 
included once more on command level, as specified for the Gx application. DCC sub-sessions shall not be used. 

If during a Gx over Gy session, the Gy server indicates DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE as 
defined in 3GPP TS 32.299 [9], then the session shall be maintained using the original Gx over Gy Application-id, i.e. 
shall not switch over to the Gx Application-id. 

The Experimental-Result-Code AVP specific values of both the Gy protocol and Gx protocol apply for the Gx over Gy 
application. 

All AVPs mandated for the Gx protocol or for the Gy protocol are also mandated for the Gx over Gy application. 

Both the procedures defined for the Gx protocol and the procedures defined for the Gy protocol shall be applied for the 
Gx over Gy application as clarified in the subsequent Clause. 

6.2.1 Simultaneous charging rule provision and credit authorization 

When the CRF uses the charging rule install AVP to install new charging rule(s) or to activate predefined charging 
rule(s) at the TPF, the collocated OCS should simultaneously provide new quota for the related service data flows if 
they are online charged and no previously allocated quota are used. The OCS shall link the new service data flows 
matching the new charging rules to allocated quota. Therefore, for predefined charging rules, that are activated by the 
CRF, the collocated OCS/CRF needs configured knowledge if they will be online charged and how they are rated. 

For the predefined charging rules that are always active at the TPF and online charged, the TPF requests credit using 
normal Gy procedures. This request should be combined with the request for charging rules at bearer establishment. 

If the TPF receives an reauthorization request message, it shall request both charging rules and credit re-authorization. 
The TPF should combine both requests in a single CC-request. 

If during bearer modification both event and re-authorization triggers apply at the same time, the TPF shall request both 
charging rules and credit re-authorization. The TPF should combine both requests in a single CC-request. 

The CC-Sub-Session-Id AVP shall not be used in the Gx over Gy Application as DCC subsessions are not used in this 
Application as indicated in this specification, clause 6.2, and in the Gy online charging Application 3GPP TS 32.299 [9] 
and TS 32.251 [13]. 



£75/ 



3GPP TS 29.210 version 6.3.0 Release 6 



21 



ETSI TS 129 210 V6.3.0 (2005-09) 



Annex A (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


2004-03 










Presented to CN3#31 bis for information 




0.0.1 


2004-04 










Updated to be used as a basis for email work 


0.0.1 


0.1.0 


2004-04 










Submitted for email work 


0.2.0 


0.1.0 


2004-05 










Submitted for CN3 meeting 


0.2.0 


0.3.0 


2004-05 










TS number 29.910 reserved, version for email discussion after 
CN3#32 


0.3.0 


0.4.0 


2004-08 










Erroneous TS number corrected to 29.21 0. Tdocs N3-040458, N3- 
040597, N3-040566, N3-040504, N3-040605 are agreed at 
CN3#33 and incorporated. To be presented to NP#25 for 
information 


0.4.0 


1.0.0 


2004-08 










Editorial Corrctions made by MCC to align with 3GPP drafting rules 


1.0.0 


1.0.1 


2004-10 










Several Tdocs agreed at CN3#33Bis incorporated 


1.0.1 


1.1.0 


2004-11 










Several Tdocs agreed at CN3#34 incorporated. To be presented to 
NP#26 for approval 


1.1.0 


2.0.0 


2004-12 


CN#26 








Upgraded to Release 6 


2.0.0 


6.0.0 


2005-03 


CN#27 


NP-050109 


1 


3 


Extend the Rule Name uniqueness to the TPF for static rules 


6.0.0 


6.1.0 


2005-03 


CN#27 


NP-050109 


3 


2 


Missing description of the behaviour of the application-ids on 
NOT APPLICABLE notifications 


6.0.0 


6.1.0 


2005-03 


CN#27 


NP-050109 


5 


1 


Indication of Bearer Termination 


6.0.0 


6.1.0 


2005-03 


CN#27 


NP-050109 


6 


4 


TFT filter usage 


6.0.0 


6.1.0 


2005-03 


CN#27 


NP-050109 


7 


2 


Correction of AF and Bearer Session Definitions 


6.0.0 


6.1.0 


2005-03 


CN#27 


NP-050109 


9 


2 


RAT-Type AVP definition 


6.0.0 


6.1.0 


2005-06 


CP#28 


CP-050045 


10 


1 


Various Corrections 


6.1.0 


6.2.0 


2005-06 


CP#28 


CP-050045 


11 


3 


Code allocation for Gx interface 


6.1.0 


6.2.0 


2005-06 


CP#28 


CP-050045 


13 


1 


Flow AVP only needed when ICID present 


6.1.0 


6.2.0 


2005-06 


CP#28 


CP-050045 


15 


2 


Removal of DCC sub-sessions 


6.1.0 


6.2.0 


2005-06 


CP#28 


CP-050045 


16 




Addition of the PLMN change value in the Event-Trigger AVP 


6.1.0 


6.2.0 


2005-06 


CP#28 


CP-050045 


17 




Correction of reference 


6.1.0 


6.2.0 


2005-06 


CP#28 


CP-050228 


18 


3 


Gx Auth-Application-ld AVP use 


6.1.0 


6.2.0 


2005-09 


CP#29 


CP-050448 


19 


7 


Removal of DCC sub-sessions 


6.2.0 


6.3.0 


2005-09 


CP#29 


CP-050381 


20 


2 


Charging Rule operations 


6.2.0 


6.3.0 


2005-09 


CP#29 


CP-050381 


21 


2 


NASREQ Reference update 


6.2.0 


6.3.0 


2005-09 


CP#29 


CP-050381 


22 




Ry Removal 


6.2.0 


6.3.0 


2005-09 


CP#29 


CP-050381 


25 


2 


Corrections of terminology 


6.2.0 


6.3.0 



£75/ 



3GPP TS 29.210 version 6.3.0 Release 6 



22 



ETSI TS 129 210 V6.3.0 (2005-09) 



History 



Document history 


V6.0.0 


December 2004 


Publication 


V6.1.0 


March 2005 


Publication 


V6.2.0 


June 2005 


Publication 


V6.3.0 


September 2005 


Publication 









£75/ 



